In recent weeks (as many will know) several people have asked about how to determine the different disk drives that we have available to us.
Several methods, and example programs have been posted in response to these questions, but alas, none of them have been "complete", in that they recognise some drives, but not all of them.. not to mention the fact that none of those that I've seen have attempted to identify a CMD drive in its emulation modes.
Although all the required information is readily available, in the form of programs such as POLLDEVS and WHEREAMI by Doug Cotton and others, it appears that no one has collaborated all this information into a single program.. until now :-)
What follows is just something that I cooked up as an aid to the fledgling programmers out there.. please feel free to use and distribute this program in any way you see fit.. It will detect the following drive types... 1541, 1571, 1581, CMD HD, FDxx, Ramdrive and Ramlink, and for the more adventurous among you, Paul Gardner-Stevens 64net.
With the CMD drives it will also report the following partition types.. Native, 1541, 1571, 1581, CP/M (HD only) and DACC partitions.
If anyone knows reliable ways to detect drives such as the Lt.Kernal, Datachief, SFD1001, or any other drive PLEASE forward this information to me so that I can update this program to make it the definitive drive detection program.
Enjoy.
--- Text Import Start ---
10 rem ***** identify disk drives ***** rod gasson 21/11/95
20 :
30 for dv=8 to 16
40 :
50 open15,dv,15 : close15 :
60 if st= -128 then print "device"dv"Not online" : goto420
360 if a$="4" and b$= chr$(177) then print" 1541" : goto420
370 if a$="7" and b$= chr$(177) then print" 1571" : goto420
380 if a$="8" and b$= chr$(182) then print" 64 net" : goto420
390 :
400 print "unknown drive"
410 :
420 close15 : next
--- Text Import End ---
---------------------------
Drivetype Detection
From : Rod Gasson
Myke Carter writes:
MC> I'm confused about how to glean a six-character string of text from a single address in a drive-ROM.
This info is in the user guide of most (all?) CBM disk drives, but since it is so short and easy, I'll save you the trouble of looking (assuming you have such a guide).
10 open 15,dv,15 :rem open command channel
20 print#15, "m-r"chr$(<address)chr$(>address)chr$(# of bytes)
30 get#15, <byte>,<byte>,<byte> .... etc
40 close 15
So if you wanted to read 6 bytes from $fea0, you first need to determine the low and high bytes of $ffe0 ... in decimal.
$ffe0 has a high byte of $ff, and a low byte of $e0 .. converted to decimal, this is highbyte=255, low byte = 224
If we insert this into line #20, it will look like
20 print#15, "m-r"chr$(224)chr$(255)chr$(6)
^^^ ^^^ ^
low high # of chars.
Since you have told it to read 6 bytes, you need to GET them.. so line 30 will then read
30 get#15, a$,b$,c$,d$,e$,f$
You can of course use a loop to read the six bytes, but this way makes it easier to see what you are doing.
That is all there is to it really... to read other locations of the drive memory you simple change the two address bytes, plus te number of bytes you wish to read.
MC> When he suggests looking for "CMD xx" at $FEA0, I'm left to assume that I should establish a string-building loop which reads from addresses $FEA0, $FEA1, $FEA2, $FEA3, $FEA4, and $FEA5.
You assume correctly.
MC> Or perhaps I should only read from $FEA4 and $FEA5 because if the 4, 7, and 8 tests are performed first and fail
I don't have Ed's code handy at the moment, so I can't say.
MC> cannot the "CMD " portion be assumed? At any
Possibly, and even probably... However, the idea is to *correctly* identify the drive type at all times, and since this "CMD" identifier is a known constant for CMD drives, then why not play it safe and use it ? I know what you are getting at though, and like I say, you are probably correct.. 'Course, you could also just read one byte at $FEA4 (Eds values) and if it is a "C" then assume it is a CMD device.. But who knows, at some stage in the future (or past) there may be another (non-CMD drive) that also happens to return this value at this location.
MC> rate, reading from drive-ROMs is a relatively new thing for me and it would just be so much more helpful to actually have a sample program to look at along with the list that Ed sent.
As you can see, a "sample" program consists of just a few lines.. how much you expand on this is up to you.. Remember though that you will be looking at different locations for different "identifiers" for the different drives, so you WILL need to do more than one m-r for each of the drive types you are attempting to identify.. The example that Russell posted is really nothing more than my few lines above, that has been expanded out to cater for the different drives that it detects. To add Ed's CMD info is just a matter of expanding that a little further.
MC> suggested method. It's just easier for me to have something to RUN and work with the first time around.
Which is why I have opted to give you the absolute minimum example possible.. if you can follow those few lines above, the rest will tend to fall into place (he says hopefully).
MC> RG> My *personal* advice, since you don't have a CMD drive is to not consider them at all.
MC> That has basically been my attitude all along but since I have learned the BASICs of using direct access commands to manipulate disk data, I have less difficulty imagining what is actually happening inside an emulation partition (as far as my programming is concerned) and if I can at all avoid an obvious mistake that could render my program incompatible with a CMD device, I'll do it.
As I said once before, one of the nice things about the CMD drives is that the average programmer doesn't have to take any special steps to cater for them... to take full advantage of them is a different story though. Leave that until you get one..
MC> RE: What is an "excelerator plus"...?
MC> RG> It is a 1541 "clone".
MC> I have since learned that it is an FSD-2 drive. I am vaguely familiar
Yup, but the DOS (which is what you are interested in) is no different than a regular '41
MC> RE: head "chatter" when accessing side 2 of a 1571 disk
MC>
MC> I can't say I've never noticed this head "chatter" you refer to coming from my drive. Is it just a cosmetic
I'd say cosmetic.. but I dunno enough about what is really going on, or what the fix was to say for sure.
MC> thing or should I seriously look into getting my old ROMS upgraded? Would Jiffy-DOS do the trick (because I'm already preparing to upgrade it that way)?
Yes, JiffyDos has the bugfix code in the ROMS, and this is definitly the way to go... I certainly wouldn't recommend spending out on a straight DOS upgrade... JiffyDos is well worth the expense though.
MC> RG> send a series of block-read commands to the drives and read the error channel.
MC> This was the first thing I tried although I don't think I checked the error channel after I sent the commands.
<hehehehehe>, this reminds me of one of my first programming puzzles.. I wrote this real gee-whizz program (forget what it was), that had lots of DATA statements, but it took me ages to figure out why it didn't work.. I never realised that I had to READ these DATA strings into variables.. <gee, how embarrassing>. I still have a note scribbled in my C128 user guide, that says "Rod.. you must READ DATA before you can use it"..
MC> Instead, I got frustrated because attempting to read from track 80 on a 1571 didn't result in a flashing red light on my drive.
Thats because you are reading the DRIVE MEMORY, not the DISK.. The flashing light indicates a DISK error.
MC> Perhaps I abandoned this strategy just a little bit too soon!
Probably, but what the heck, it helps to experiment and try different things anyway.
MC> Reading an error channel is probably the one thing I need most to practice - especially since I'm now writing softare with Loadstar in
I agree, but NOT because you are planning it for LS, do it because not only is it the correct thing to do, and the safe thing to do... do it because it is essential... *especially* when you are planning on modifying disk directorys.. you CANNOT afford to skimp on error checking when dealing with such a "sensitive" area of the disk.
MC> RG> At least one of the versions of QWKRR used this method, for pretty much the same reasons that you want it.
MC> Ah, so even though it's a "brute force" tactic it still passes as a correct method for acquiring the desired information. Good! It makes
When it comes to programming there isn't really any such thing as an INCORRECT method of aquiring information (I'm sure some will dissagree). Not all methods are good practice, but if it works, its a valid method.
MC> me feel good to know that I can at least think along correct paths like this without first requiring outside help. Now if I just wouldn't
STAY WITH THIS. Asking for help will only get you known, tried and true methods, and while this is often a good thing, it can also limit you... it was only because I didn't know that reading QWK mail "couldn't be done" on a commodore that enabled me to do it. I know this sounds "weird", but its true.. before I had regular access to this echo, there were (apparently) many discussions as to why it wasn't possible for a C= to do this, so no one ever really tried.. I was isolated from these discussions, and managed to obtain the file structure for the mail packets... it didn't take me long at all before I had my first rudimentary OLR (written in BASIC).. I was REALLY surprised when I discovered this echo and realised I'd acheived what people were saying couldn't be done... Anyway, the point is, don't be afraid to experiment and try new ideas.. give yourself the freedom to go where no man has gone before..
MC> RG> drive in Native mode, and in this case the directory is on track#1, sector#1,
MC> Other than that are there any differences between way the directory track information of a CMD native mode partition is handled compared to the way the original Commodore drives do it? If not, that's good
No, not really... but since the CMD drives can date stamp their files there are differences that you should consider.. Such date stamps are stored in bytes 23-27 of each of the file entries.. Bytes 22-25 are usually "unused", and bytes 26-27 are normally used for the track/sector when saving a file with save-with-replace.. CMD have modified these routines in thier drives though, so these bytes are also unused.. except for the date stamp.
MC> RG> I gather that you are aware that Loadstar has several "requirements" of programs it purchases? If not then I suggest you
MC> My wife and I actually visited Fender's and Jeff's offices (way up there in the clouds over Shreveport) in September when we were on vacation. I can't recall them mentioning any specific "requirements"
Did you ask ?
MC> multiple IF...THEN statements when it comes to checking the values of keys being pressed when menu options are given. I pay great heed to all of the above as I write program(s) for submission to them.
MC> What else have I not listed?
I dunno, its been a long time since I saw the list... I thought there was one that specified that the program needs to reload Loadstar itself when exiting.. Don't forget that these are only guidelines though.. the better the program, the more they are likely to accept it even if the guidelines aren't followed.
MC> Am I on the right track regarding the "requirements" to which you allude?
Yup.
------------------------
1581 info required
From : Rod Gasson
Hopefully someone here can help me.
I'm looking for the memory location in a 1581 disk-drive that holds the buffer number for the LAST sector read (IE, the currently active buffer).
Up until now I have been using location $6c for this, but this has turned out to be unreliable when more than one file is opened.
I ran into a similar problem a while ago on the 1541/71.. I was using $f9, but this too was unreliable with more than one file open.. I have since found that $3f is a more reliable location. Unfortunetly I've had no success in finding a similar location on the '81
Anyway, since I've been dabbling with this stuff, for anyone that is interested, I've got determined that the active buffer in the following drives can be found at :
Drive Buffer location
1541/71 $3f
Ramlink $62
Ramdrive $62
CMD HD $d3
CMD FD $6c
1581 ??
Oh, one thing that I've found of interest.. the location $6c on a JiffyDossed 1581 does return the correct buffer#, but with JD disabled it is only correct about 80% of the time (at a guess).
Also, if anyone can confirm that the locations I have for the CMD drives are correct (or not) I'd greatly appreciate it 'cos I found them only by experimentation.
-----------------------
Peripherals Wanted
From : Rod Gasson
To : John Larkin
Hi John,
I'm Playing Devils Advocate here..
...Whilst speaking to Ryan Nash-Arjoon, you said:
JL> Cassette software was the curse of the C-64!
I disagree. Cassette software was readily available and cheap, and required a minimum of hardware to access it. If it weren't for cassettes the C64 probably wouldn't have enjoyed the success that it had.
JL> It spawned too many cheesy games
It also spawned some classics.
JL> because companies had to try and make the game load all in one shot.
There was no technical reason why this had to be this way though.. Admittedly there would be some limitations that disks don't have, but there is still no reason for the entire program to be in memory at once. Personally I prefer a single part program over a multi-part one anyway. The tend to play better. Mind you, I'm also the kind of person that rarely plays computer games anyway.
JL> This is how crap like Outrun and Space Harrier got made.
I don't think I've seen Space Harrier, but I have played Outrun, and I can only say that for a game that had its origins as a "crap" tape game it did kind of well for someone to consider porting it to 16bit arcade games machines.
JL> I used a datasette for the first year I had the C-64 and I *HATED* it.
Thats ok, for a lot of people it is datasette or nothing. I've had both, and I'll take the datasette anytime, thank you.
JL> Programs took forever to load and I
As a general rule this is true, but with turbo tape loaders some games will load faster from tape than the same game from the stock 1541.
JL> always had trouble finding the one I wanted off the tape. I usually ended up
That is YOUR problem, not a fault of the tape ;-)
JL> using the trick where you stop it halfway through the loading process while it's reading the second copy, just
I never used this trick.. I never used a datasette for long enough to learn it.
JL> to speed it up. I own exactly ONE commercial game on tape and it takes about 15 minutes to load, WHEN it loads!
There are several cartridges available that will let you capture tape programs so they can be loaded from disk. If its a game you like then thats prolly the best thing to do.
JL> Maybe without cassettes, there wouldn't have been as many C-64's sold, but
Thats what I said at the start.
JL> without cassettes, maybe there wouldn't have been as many games that were compromised so that the authors could cram everything into memory at once instead of making each level the best it could be.
Have you never considered that some of the games are BETTER because of this.. it teaches the authors to write small and efficient code to fit in the limited amount of memory.. Look at all the crappy disk based programs there are around that have made use of multipart loading, but all you get from it is a lot of pretty graphics, a lot of music, but very little "playable" content.
JL> Also, British games wouldn't work correctly in the US because they'd be in PAL mode and the US uses NTSC.
This has little to do with them being tape based programs.. Most tape based programs that I've seen haven't been "advanced" enough to take full advantage of FLI graphics etc where things become time critical. Having said that though, I can see problems with LOADING these programs saved on a tape recorded in an NTSC country.. the reason being that the datasette itself runs at a slightly different speed.. how critical this is I wouldn't know.
-------------------------
From : RYAN NASH-ARJOON
To : JOHN LARKIN
Subj : Cassette Software
Hi John
Some cassette games for the 64 were crap, but are you saying all "disk only" games were brilliant?
As for cassette software being responsible for the whole genre of second rate games I have to disagree. The two games you mentioned were converted from arcade machines. In reality it is foolish to expect a faithful conversion of a 16 bit arcade game to a 64K 8 bit home computer, but every time one came out we would always hope that it would be exactly like the original arcade machine.
Having said that, when it comes to *arcade* conversions cassette or disk media really has nothing to do with it. In my opinion *arcade* conversions have *always* turned out pretty badly. Gauntlet and Commando were also scraping the bottom of the barrel. The reason why the "crap like Outrun and Space Harrier got made" is because the companies were more interested in recovering their expenses paid for buying the rights or "Official License" of the game from the arcade company. Coupled with the limitations of the 64 the actual quality of the conversion is bound to take a back seat.
As for companies having to make a game load in one shot, that's not true. Off the top of my head take a look at the Epyx series of Summer Games, Winter Games etc. They were designed for disk, but are extremely playable on cassette. And there's no hard and fast rule saying that *all* cassette games have to be identical to their disk counterparts: look at Microprose's Gunship. This game was originally designed for disk and is a complex multi-loader. Because of the complexity of the multiload, the cassette version had to omit parts of the game.
I'm originally from the UK, but I can tell you that Disk Drives were damn expensive. They would cost the same as the 64 itself, and I paid <250 (about $375) for my 64C in 1987. Cassette software would cost <10 ($15) and disk software (near impossible to find) would cost at least <15 ($23). Many of us never had the opportunity to use a disk drive, so we weren't going to miss something we had never experienced in the first place! The Datasette provided with the 64 was what we were used to using. Quite simply, in 1987 disk drives were considered an unnecessary luxury, and waiting 5 minutes or so for a game to load was more than acceptable. If somebody didn't like the wait then they should find another hobby!
When the 64 first came out, the cassette software *would* take forever to load (about 20 minutes or so). But those games are really old and now very rare. Most of the newer games (from say 1986 onwards) used Turbo/Nova/Pav etc loaders and would cut the load time to just 5 minutes! From 1986 the actual quality of games increased too!
Why didn't you make a note of the tape counter readings before each program starts? That's what I do and it saves me a heck of a lot of time!
JL> Maybe without cassettes, there wouldn't have been as many C-64's sold, but without cassettes, maybe there wouldn't have been as many games that were compromised so that the authors could cram everything into memory at once instead of making each level the best it could be.
I dunno. But I do know that the 64 was a mega popular machine in the UK and not many of us had disk drives.
Like I said earlier, just because a game is on cassette doesn't mean it has to load in one shot. There are many cassette multi-load games: the Epyx series of Summer Games, Winter Games, World Games, Summer Games II, Infiltrator, Leaderboard, The Fourth Protocol, Super Cycle, Hardball to name just a few!!!
JL> Also, British games wouldn't work correctly in the US because they'd be in PAL mode and the US uses NTSC.
It's just as well I have a European and US 64!! I also have a European Vic20 and it still works!!
